The invention relates generally to transaction processing, and particularly to a two-phase commit (2PC) transaction protocol for use between transaction processing systems interconnected by a network.
Transaction processing, among other things, often involves a change in state of some form of information collection (e.g., xe2x80x9cdatabasexe2x80x9d). In fact, a transaction is often defined as an explicitly delimited operation, or set of operations, that change or otherwise modify the content of the database from one consistent state to another. Changes or modifications are treated as a single unit in that all changes/modifications of a transaction are formed and made permanent (i.e., the transaction is xe2x80x9ccommittedxe2x80x9d), or none are made (i.e., the transaction is xe2x80x9cabortedxe2x80x9d). Failures occurring during the execution of a transaction may result in the transaction being aborted, and whatever partial changes were made to the database can be undone to return it to a consistent state.
A paradigm has been developed to insure that the conclusion of a transaction results in maintaining the consistency of the database. Known as the xe2x80x9ctwo-phase commitxe2x80x9d (2PC) protocol, this paradigm provides a procedure to coordinate the operation of resources whose participation has been enlisted in the transaction in a name that insures that the participating resources effect the desired change. For example, a transfer of funds from an account of one depositor to the account of another depositor of the same bank will result in a debit to the account of the first depositor, and a concomitant credit to the account of the second depositor, all of which can be handled by a transaction. The bank application will initiate the transaction, perhaps calling upon the services of a disk process resource to retrieve the account information of one depositor so that the debit can be made. Another disk process resource may be employed to retrieve the account of the other depositor to credit that account. In this example, and according to the 2PC protocol, the transaction will conclude with both disk process resources agreeing that the changes have been made according to the 2PC protocol.
Of course, the 2PC protocol is most often used in a homogeneous transaction processing system such as a single multi-tasking processor unit, or one with multiple processor units tightly interconnected in a cluster arrangement. Initiating transactions, and monitoring those transactions between different transaction processing systems, whether heterogeneous or homogeneous, can be a bit more difficult. However, recently there has been proposed a Transaction Internet Protocol (TIP), using the 2PC paradigm by a Transaction Internet Protocol working group of the Internet Engineering Task Force (IETF). This protocol has now been formally accepted as a formal standard (RFC) by the IETF. Attached hereto, as Appendix A is the final version of the IETF paper describing TIP and its requirements.
Briefly, the papers describe a simple 2PC protocol applicable to transactions involving resources in a distributed, Internet-connected transaction. Basically, two models are suggested: a xe2x80x9cPushxe2x80x9d model and xe2x80x9cPullxe2x80x9d model. The Push model is initiated by an application on a first transaction processing system making a request of the transaction manager of that system to xe2x80x9cexportxe2x80x9d a transaction to a second transaction monitoring system to perform some work on behalf of the application. The transaction manager of the first system will xe2x80x9cpushxe2x80x9d the transaction to the second system by sending a message to the transaction manager of the second system. The message asks the second system to start a transaction as a subordinate of the first system, and return the name, for example xe2x80x9cX,xe2x80x9d, for that transaction on the second system together with the Internet address of the transaction. The application on the first system will then send a message to the desired resource (e.g., a disk process) on the second system, asking it to xe2x80x9cdo some work, and make it part of the transaction that your transaction manager already knows of by the name of X.xe2x80x9d Because the first system""s transaction manager knows that it sent the transaction to the second system transaction manager, the first system transaction manager knows to involve the second system transaction manager in the 2PC process.
In the Pull model, the application on the first system merely sends a message to a resource on the second system, requesting that it xe2x80x9cdo some work, and make it part of a transaction that my transaction manager knows by the name of Y.xe2x80x9d The resource process on the second system then asks its transaction manager to enlist in the transaction Y. At that point, the transaction is locally initiated on the second system, and the second system transaction manager will xe2x80x9cpullxe2x80x9d the transaction (Y) over from the first system. As a result of this pull, the first system""s transaction manager knows to involve the second system""s transaction manager in the 2PC process.
In the Pull model, the resource must wait to perform the task requested of it by the application until the transaction manager of the second system receives the Pull response from the first system and then notifies the resource to proceed. Unfortunately, this pull of a transaction can be time consuming.
The present invention provides a modification to the Pull model of the Transaction Internet Protocol that allows for much more efficient and faster operation.
According to the present invention, at least first and second transaction processing systems are available, each including a transaction manager and various resources applicable for use in a transaction. The two systems are coupled for access to the Internet for communicating therebetween. An application program resident on the first system initiates a transaction, and as a part of that transaction, sends a request for work to be performed by a resource managed by a process (the recipient of the request) on the second system. The request will contain an identification of the transaction. The recipient process will notify its associated transaction manager which, in turn, will initiate a (second) transaction at the second system. When the second transaction is created, the transaction manager will instruct the recipient process to perform the requested activity under the aegis of the second transaction, and then notify the transaction manager of the first system of the second transaction together with the identification of the associated transaction at the first system. The transaction manager of the first system (now, the xe2x80x9cBeginnerxe2x80x9d transaction manager), upon receiving the identification of the transaction started on the second system, will register that transaction as a subordinate to the transaction initiated at the first system, and will send a xe2x80x9cPull Responsexe2x80x9d to the transaction manager (now, the xe2x80x9cSubordinatexe2x80x9d transaction manager) on the second system that the registration has been completed. The recipient process, when its requested task is complete, will check with its (local) transaction manager, the Subordinate transaction manager, to determine if the Pull Response has been received. If so, the recipient process will respond as necessary to the application program of the first system. To conclude the transaction, the application program initiates and xe2x80x9cEnd Transactionxe2x80x9d to cause the transaction manager to initiate the two-phase commit protocol. This will include the transaction manager of the second system.
A principal advantage of the invention is that TIP technique is employed to perform a transaction over two systems connected by an Internet link in a manner that precludes a recipient process from having to wait until its associated (Subordinate) transaction manager receives back a Pull Response from the Beginner transaction manager of the first (requesting) system. Rather, while the second system is waiting for that Pull response, the associated recipient process has initiated the requested activity, and can be ready to reply to the requesting application when the Subordinate transaction manager receives the Pull Response from Beginner transaction manager on the first system.
These, and other aspects and advantages of the present invention, will become apparent to those skilled in this art upon reading of the following detailed description of the invention, which will be taken in conjunction with the accompanying FIGURE.